TMeter позволяет вести протокол пакетов, попавших в фильтр. Для этого каждый фильтр имеет свой независимый коллектор пакетов. Коллектор - это специальное "хранилище" для пакетов. Хранить информацию о каждом собранном пакете неразумно, т.к. для каждого сеанса связи пакеты, как правило, имеют общие характеристики (например, протокол, адрес источника и назначения и т.п.). Поэтому пакеты в коллекторе собираются в специальные "ячейки" или "позиции". Размер коллектора задается в позициях. Каждая позиция хранит следующую информацию о пакетах попавших в фильтр: - тип протокола - адрес и порт отправителя - адрес и порт получателя - размер переданных и принятых байт
 
Коллектор пакетов каждого фильтра, в свою очередь, состоит из двух частей - realtime-коллектора и flush-коллектора. В Realtime-коллектор помещаются собранные пакеты которые удовлятворяют по-крайней мере одному правилу входящему в фильтр. Размер realtime-коллектора задает пользователь в редакторе фильтра (от 100 до 1000 позиций). Всегда следует помнить, что большой размер коллектора пакетов (более 800 позиций) и высокая интенсивность попаданий пакетов в фильтр понижает производительность системы, т.к. при каждом попадании пакета в фильтр просматривается весь коллектор на предмет поиска подходящей позиции для пакета. Если свободной позиции для нового пакета в realtime-коллекторе не обнаружено, то это означает "переполнение realtime-коллектора". Переполнение realtime-коллектора означает, что часть информации о пакетах, попавших в фильтр будет утеряна. Поэтому, при регулярном переполении realtime-коллектора его размер можно увеличить или уменьшить интервал записи коллектора.
 
При наступлении события, называемого "сбросом коллектора" в файл или в базу данных, содержимое realtime-коллектора копируется в flush-коллектор. Далее содержимое realtime-коллектора очищается, а содержимое flush-коллекторa записывается в файл или в базу данных. В случае удачной записи flush-коллектора его содержимое очищается и он готов к приему очередной порции данных из realtime-коллектора. Если содержимое flush-коллектора записать не удалось по какой-либо причине (например, связь с базой данных потеряна), то несохранненные данные из flush-коллектора будут записаны при наступлении следующего события "сброс коллектора". Размер flush-коллектора - 2000 позиций.
 
При записе в файл необходимо в окне редактирования фильтра задать шаблон файлов для протоколирования пакетов. Поскольку каждый фильтр имеет свой независимый коллектор пакетов, поэтому шаблоны файлов должны быть уникальны для каждого фильтра.

Пример файла с протоколом пакетов показан ниже. Строки, начинающиеся с "---" содержат временную метку сброса коллектора пакетов в данный файл. Далее идут непосредственно данные о сетевых пакетах, которые попали в фильтр за время от последнего сброса коллектора. Первое поле - тип протокола, второе и третье поле - адрес и порт источника, четвертое и пятое поле - адрес и порт получателя, шестое и седьмое поле - количество переданных и принятых байт соответственно.

--- Time: 2001-09-12 11:32:54
 TCP 192.168.190.62  2532  192.168.190.11   143    1174    1492
 TCP 192.168.190.62  2533  192.168.190.11   143     450     811
 TCP 192.168.190.62  2534  192.168.190.11   143     471     636
 TCP 192.168.190.62  2535  192.168.190.11   143     453     809

--- Time: 2001-09-12 11:33:06
 TCP 192.168.190.62  2502  192.168.190.11  3128      80    3033
 TCP 192.168.190.62  2537  192.168.190.11  3128     562    1562
 TCP 192.168.190.62  2538  192.168.190.11  3128     547    1562
 TCP 192.168.190.62  2539  192.168.190.11  3128     557    1562

--- Time: 2001-09-12 11:34:42
 TCP 192.168.190.62  2502  192.168.190.11  3128      80    1541
 TCP 192.168.190.62  2540  192.168.190.11  3128     557    1562
 TCP 192.168.190.62  2541  192.168.190.11  3128     615    1562

Как видно из примера лог-файла пакетов выше, открытие одной web-странички в Интернет-браузере приводит к установлении нескольких TCP-соединений одновременно. Поэтому, чтобы сократить объем протоколируемой информации, TMeter применяет так называемый режим "компрессии непривилегированных портов". Суть его в следующем. Как известно, существует два типа TCP- и UDP-портов: "привилегированные" (порты с номерами от 0 до 1023) и "непривилегированные" (порты с номерами от 1024 до 65535). Как правило, привилегированные порты используют различные сервисы (например, порт 80 - протокол http, порт 53 - протокол DNS), а непривилегированные порты используются клиентскими программами. В режиме компрессии непривилегированных портов во всех соединениях типа "клиент-сервер" клиентский порт будет заменяться на число 65535. Это число указывает на то, что один из участников соединения использовал клиентские порты (1024-65535). Таким образом, привеленный выше фрагмент лог файла будет сжат:

--- Time: 2001-09-12 11:32:54
 TCP 192.168.190.62  65535  192.168.190.11   143    2548    3748

--- Time: 2001-09-12 11:33:06
 TCP 192.168.190.62  65535  192.168.190.11  3128     142    7539

--- Time: 2001-09-12 11:34:42
 TCP 192.168.190.62  65535  192.168.190.11  3128     123    4598

Отменить использование режима компрессии непривилегированных портов можно прописав параметр NoCompressNonPrivilegedPorts=1 в секцию описания фильтра tmf-файла.

При записи пакетов в базу данных необходимо создать OLE DB инитстроку подключения к базе данных и таблицу в базе данных. TMeter сам создавать таблицу в базе данных не умеет. Для более подробной информации о настройке подключения к базе данных см. документ "Протоколирование пакетов в базу данных".